<html>
 <link href="../enzo.css" rel="stylesheet" type="text/css"> 
  <head>
    <title>Writing Enzo Parameter Files</title>
  </head>
<body> 

    <h1>Writing Enzo Parameter Files</h1>

    <p>Putting together a parameter file for Enzo is possibly the most critical step
      when setting up a simulation, and is certainly the step which is most fraught
      with peril.  There are over 200 parameters that one can set -
      see the <a href="../amr_guide/index-enzo.html">parameter list</a> for a complete 
      list.  For the most part, defaults are set to be sane values for cosmological 
      simulations, and most physics packages are turned off by default, so that you have
      to explicitly turn on modules.  All physics packages are compiled into Enzo (unlike
      codes such as Kronos or ZEUS-MP, where you have to recompile the code in order to enable 
      new physics).</p>

    <p>
      It is inadvisable for a novice to put together a parameter file from scratch.
      Several parameter files are available for download, which go along with the initial
      conditions files provided on the page on 
      <a href="ics_top.html">generating initial conditions</a>.  The simulations include
      (links go to simulation parameter files):</p>
    
    <ul>
      <li><a href="SingleGrid_dmonly_amr.param">a dark matter-only AMR simulation</a>, 
      <li><a href="SingleGrid_dm_hydro_unigrid.param">a unigrid dark matter + hydro simulation</a>,
      <li><a href="SingleGrid_dm_hydro_amr.param">an AMR dm + hydro simulation refining everywhere</a>
      <li><a href="MultiGrid_dm_hydro_amr.param">an AMR dm + hydro simulation with multiple nested
      grids</a>.
    </ul>
    <p>
      In order to make the most of this tutorial it is advisable to have one or more of these
      parameter files open while reading this page.  For the purposes of this tutorial we assume
      that the user is putting together a cosmology simulation and has already generated the 
      <a href="ics_top.html">initial conditions</a> files using <tt>inits</tt>.
    </p>
    <p>
      All parameters are put into a plain text file (one parameter per line), 
      the name of which is fed into Enzo at execution
      time at the command line.  Typically,
      a parameter is set by writing the parameter name, an equals sign, and then the parameter value
      or values, like this:
    </p>
    <p>
      <tt>NumberOfBufferZones = 3</tt>
    </p>
    <p>
      You must leave at least one space between the parameter, the equals sign, and the parameter value.  
      It's fine if you use more than one space - after the first space, whitespace is unimportant.  
      All lines which start with a # (pound sign) are treated as comments and ignored.  In addition,
      you can have inline comments by using the same pound sign, or two forward slashes ( // ).
    </p>

    <p>&nbsp;</p>

    <h2>Initialization parameters</h2>
    <p>Complete descriptions of all initialization parameters are given 
      <a href="../amr_guide/index-enzo.html#Initialization Parameters">here</a>.
      The most fundamental initialization parameter you have to set is <tt>ProblemType</tt>, which 
      specifies the type of problem to be run, and therefore the way that Enzo initiates the data.
      A cosmology simulation is problem type 30.  As started before, 
      for the purposes of this introduction I'm 
      assuming that you are generating a cosmology simulation, so you would put this line in the 
      parameter file:</p>

    <p>
      <tt>ProblemType = 30</tt>
    </p>

    <p><tt>TopGridRank</tt> specifies the spatial dimensionality of your problem (1, 2 or 3 dimensions),
      and must be set.  TopGridDimensions specifies the number of root grid cells along each axis.  For
      a 3D simulation with 128 grid cells along each axis, put this in the parameter file:</p>

    <p>
      <tt>TopGridRank = 3</tt><br>
      <tt>TopGridDimensions = 128 128 128</tt>
    </p>

    <p>Additionally, you must specify the names of the initial conditions files with contain 
      the baryon density and velocity information and the dark matter particle positions
      and velocities.  These are controlled via the parameters <tt>CosmologySimulationDensityName</tt>,
      <tt>CosmologySimulationVelocity[123]Name</tt> (where 1, 2 and 3 correspond to the 
      x, y and z directions, respectively), <tt>CosmologySimulationParticlePositionName</tt>
      and <tt>CosmologySimulationParticleVelocityName</tt>.  Assuming that the baryon velocity information
      is all in a single file, and that the baryon density and velocity file names are GridDensity and
      GridVelocities, and that the particle position and velocity files are named ParticlePositions and
      ParticleVelocities, these parameters would be set as follows:</p>

    <p>
      <tt>CosmologySimulationDensityName          = GridDensity</tt><br>
      <tt>CosmologySimulationVelocity1Name        = GridVelocities</tt><br>
      <tt>CosmologySimulationVelocity2Name        = GridVelocities</tt><br>
      <tt>CosmologySimulationVelocity3Name        = GridVelocities</tt><br>
      <tt>CosmologySimulationParticlePositionName = ParticlePositions</tt><br>
      <tt>CosmologySimulationParticleVelocityName = ParticleVelocities</tt><br>
    </p>
    
    <p>
      Some more advanced are parameters in the 
      <a href="../amr_guide/index-enzo.html#Initialization Parameters">Initialization Parameters</a> 
      section control domain and boundary value specifications.  These should NOT be altered unless 
      you really, really know what you're doing!
    </p>

    <p>&nbsp;</p>

    <h2>Cosmology</h2>
    <p>Complete descriptions of all cosmology parameters are given
      <a href="../amr_guide/index-enzo.html#Cosmology Parameters">here</a> and
      <a href="../amr_guide/index-enzo.html#Cosmology Simulation">here</a>.
      <tt>ComovingCoordinates</tt> determines whether comoving coordinates are used or not.
      In practice, turning this off turns off all of the cosmology machinery, so you want to
      leave it set to 1 for a cosmology simulation.  <tt>CosmologyInitialRedshift</tt> and
      <tt>CosmologyFinalRedshift</tt> control the start and end times of the simulation,
      respectively.  <tt>CosmologyHubbleConstantNow</tt> sets the Hubble parameter, and is
      specified at z=0 in units of 100 km/s/Mpc.  <tt>CosmologyComovingBoxSize</tt> sets
      the size of the box to be simulated (in units of Mpc/h) at z=0.  
      <tt>CosmologyOmegaBaryonNow</tt>,<tt>CosmologyOmegaMatterNow</tt>,<tt>CosmologyOmegaCDMNow</tt> and
      <tt>CosmologyOmegaLambdaNow</tt> set the amounts of baryons, total matter, dark matter and vacuum
      energy (in units of the critical density at z=0).  An addition to the standard baryon fields that 
      can be initialized, one can create a metal tracer field by turning on 
      <tt>CosmologySimulationUseMetallicityField</tt>.  This is handy for simulations with star formation
      and feedback (described below).  For example, in a cosmology simulation with box
      size 100 Mpc/h with approximately the cosmological parameters determined by WMAP, which starts
      at z=50 and ends at z=2, and has a metal tracer field, we put the following into the parameter file:
      
    <p>
      <tt>ComovingCoordinates      = 1</tt><br>
      <tt>CosmologyInitialRedshift = 50.0</tt><br>
      <tt>CosmologyFinalRedshift   = 2.0</tt><br>
      <tt>CosmologyHubbleConstantNow = 0.7</tt><br>
      <tt>CosmologyComovingBoxSize = 100.0</tt><br>
      <tt>CosmologyOmegaBaryonNow = 0.04</tt><br>
      <tt>CosmologyOmegaMatterNow = 0.3</tt><br>
      <tt>CosmologyOmegaCDMNow = 0.26</tt><br>
      <tt>CosmologyOmegaLambdaNow = 0.7</tt><br>
      <tt>CosmologySimulationUseMetallicityField = 1</tt><br>
    </p>

    <p>&nbsp;</p>

    <h2>Gravity and Particle Parameters</h2>
    The parameter list sections on gravity particle positions are 
    <a href="../amr_guide/index-enzo.html#Gravity Parameters">here</a> and
    <a href="../amr_guide/index-enzo.html#Particle Parameters">here</a>, 
    respectively.  The significant gravity-related parameters are <tt>SelfGravity</tt>,
    which turns gravity on (1) or off (0) and <tt>GravitationalConstant</tt>, which should
    be 1 in cosmological simulations.  <tt>BaryonSelfGravityApproximation</tt> controls whether
    gravity for baryons is determined by a quick and reasonable approximation.  It should be left
    on (1) in most cases.  For a cosmological simulation with self gravity, we would put the
    following parameters into the startup file:</p>

    <p>
      <tt>SelfGravity = 1</tt><br>
      <tt>GravitationalConstant = 1</tt><br>
      <tt>BaryonSelfGravityApproximation = 1</tt><br>
    </p>

    <p>We discuss some AMR and parallelization-related particle parameters in later sections.</p>

    <p>&nbsp;</p>

    <h2>Adiabatic hydrodynamics parameters</h2>
    <p>The parameter listing section on hydro parameters can be found 
      <a href="../amr_guide/index-enzo.html#Hydrodynamic Parameters">here</a>.  The most
      fundamental hydro parameter that you can set is <tt>HydroMethod</tt>, which lets
      you decide between the Piecewise Parabolic Method (aka PPM; option 0), or the 
      finite-difference method used in the Zeus astrophysics code (option 2).  PPM
      is the more advanced, not to mention optimized, method.  The Zeus method uses
      an artificial viscosity-based scheme and may not be suited for some types of 
      work.  When using PPM in a cosmological simulation, it is important to turn
      <tt>DualEnergyFormalism</tt> on (1), which makes total-energy schemes such as
      PPM stable in a regime where there are hypersonic fluid flows, which is quite
      common in cosmology.  The final parameter that one must set is <tt>Gamma</tt>, the ratio of
      specific heats for an ideal gas.  If <tt>MultiSpecies</tt> (discussed later in this 
      tutorial) is on, this is ignored.  For a cosmological simulation where we wish to 
      use PPM and have gamma = 5/3, we use the following parameters:</p>

    <p>
      <tt>HydroMethod = 0</tt><br>
      <tt>DualEnergyFormalism = 1</tt><br>
      <tt>Gamma = 1.66667</tt><br>
    </p>

    <p>In addition to these three parameters, there are several others which control
      more subtle aspects of the two hydro methods.  See the parameter file listing of
      <a href="../amr_guide/index-enzo.html#Hydrodynamic Parameters">hydro parameters</a> 
      for more information on these.</p>

    <p>One final note:  If you are interested in performing simulations where the gas
      has an isothermal equation of state (gamma = 1), this can be approximated without 
      crashing the code by setting the parameter <tt>Gamma</tt> equal to a number
      which is reasonably close to one, such as 1.001.</p>

    <p>&nbsp;</p>

    <h2>AMR Hierarchy Control Parameters</h2>
    <p>These parameters can be found in the parameter list page 
    <a href="../amr_guide/index-enzo.html#Hierarchy%20Control%20Parameters">here</a>.  They
    control whether or not the simulation uses adaptive mesh refinement, and if so, the 
    characteristics of the adaptive meshing grid creation and refinement criteria.  We'll concentrate
    on a simulation with only a single initial grid first, and then discuss multiple levels
    of initial grids in a subsection.</p>

    <p>The most fundamental AMR parameter is <tt>StaticHierarchy</tt>.  When this is on (1), 
      the code is a unigrid code.  When it is off (0), adaptive mesh is turned on.  
      <tt>RefineBy</tt> controls the refinement factor - for example, a value of 2 means 
      that a child grid is twice as highly refined as its parent grid.  We have found that
      a value of 2 for <tt>MaximumRefinementLeve</tt> is useful for cosmology simulations, 
      though of course experimentation is encouraged.
      <tt>MaximumRefinementLevel</tt> determines how many possible levels of refinement a 
      given simulation can attain, and <tt>MaximumGravityRefinementLevel</tt> defines the
      maximum level at which gravitational accelerations are computed.  More highly refined
      levels have their gravitational accelerations interpolated from this level, which effectively
      provides smoothing of the gravitational force on the spatial resolution of the grids at 
      <tt>MaximumGravityRefinementLevel</tt>.  A simulation with AMR turned on, where there are 6
      levels of refinement (with gravity being smoothed on level 4) 
      and where each child grid is twice as highly resolved as its parent
      grid would have these parameters set as follows:</p>
   
    <p>
      <tt>StaticHierarchy = 0</tt><br>
      <tt>RefineBy = 2.0</tt><br>
      <tt>MaximumRefinementLevel = 6</tt><br>
      <tt>MaximumGravityRefinementLevel = 4</tt><br>
    </p>

    <p>Once the AMR is turned on, you must specify how and where the hierarchy refines.  The
      parameter <tt>CellFlaggingMethod</tt> controls the method in which cells are flagged, and can
      be set with multiple values.  We find that refining by baryon and dark matter mass (options 2
      and 4) are typically useful in cosmological simulations.  The parameter 
      <tt>MinimumOverDensityForRefinement</tt> allows you to control the overdensity at which a 
      given grid is refined, and can is set with multiple values as well.  Another very useful
      parameter is <tt>MinimumMassForRefinementLevelExponent</tt>, which modifies the cell 
      masses/overdensities used for refining grid cells.  See the parameter page for a more
      detailed explanation, but essentially leaving this with a value of 0.0 ensures that
      gas mass resolution in dense regions remains more-or-less Lagrangian in nature.  Negative
      values make the refinement super-Lagrangian (ie, each level has less gas mass per cell on
      average than the coarser level above it) and positive values make the refinement 
      sub-lagrangian.  In an AMR simulation where the AMR triggers on baryon and dark matter
      overdensities in a given cell of 4.0 and 8.0, respectively, where the refinement is slightly
      super-Lagrangian, these paramaters would be set as follows:</p>

    <p>
      <tt>CellFlaggingMethod = 2 4</tt><br>
      <tt>MinimumOverDensityForRefinement = 4.0 8.0</tt><br>
      <tt>MinimumMassForRefinementLevelExponent = -0.1</tt><br>
    </p>

    <p>At times it is very useful to constrain your simulation such that only a small
      region is adaptively refined (the default is to refine over an entire simulation volume).
      For example, if you wish to study the formation of a particular
      galaxy in a very large volume, you may wish to only refine in the small region around where 
      that galaxy forms in your simulation, in order to save on computational expense and dataset
      size.  Two parameters, <tt>RefineRegionLeftEdge</tt> and <tt>RefineRegionRightEdge</tt>, allow
      control of this.  For example, if we only want to refine in the inner half of the volume
      (0.25 - 0.75 along each axis), we would set these parameters as follows:</p>
    <p>
      <tt>RefineRegionLeftEdge = 0.25 0.25 0.25</tt><br>
      <tt>RefineRegionRightEdge = 0.75 0.75 0.75</tt><br>
    </p>

    <p>This pair of parameters can be combined with the use of nested initial grids (discussed
      in the next subsection) to get simulations
      with extremely high dark matter mass and spatial resolution in a small volume at reasonable
      computational cost.</p>

    <h3>Multiple nested grids</h3>
    <p>At times it is highly advantageous to use multiple nested grids.  This is extremely useful in a 
      situation where you are interested in a relatively small region of space where you need very good
      dark matter mass resolution and spatial resolution while at the same time still resolving large
      scale structure in order to get gravitational tidal forces.  An excellent example of this is formation
      of the first generation of objects in the universe, where we are interested in a relatively small (10^6 
      solar mass) halo which is strongly tidally influenced by the large-scale structure around it.  It is
      important to resolve this halo with a large number of dark matter particles in order to reduce frictional
      heating, but the substructure of the distant large-scale structure is not necessarily interesting, so it
      can be resolved by very massive particles.  One could avoid the complication of multiple grids by using
      a single very large grid - however, this would be far more computationally expensive.</p>

    <p>Let us assume for the purpose of this example that in addition to the initial root grid
      grids (having 128 grid cells along each axis) there are two subgrids, 
      each of which is half the size of the one above it in each spatial direction (so subgrid 1 spans
      from 0.25-0.75 in units of the box size and subgrid 2 goes from 0.375-0.625 in each direction).  If each
      grid is twice as highly refined spatially as the one above it, the dark matter particles on that level are
      8 times smaller, so the dark matter mass resolution on grid #2 is 64 times better than on the root grid,
      while the total number of initial grid cells only increases by a factor of three (since each grid is half the 
      size, but twice as highly refined as the one above it, the total number of grid cells remains the same). 
      Note:  See the 
      page on <a href="ics_top.html">generating initial conditions</a> for more information on creating this
      sort of set of nested grids.</p>

    <p>When a simulation with more than one initial grid is run, the total number of initial grids is specified
      by setting <tt>CosmologySimulationNumberOfInitialGrids</tt>.  The parameter <tt>CosmologySimulationGridDimension[#]</tt>
      is an array of three integers setting the grid dimensions of each nested grid, and 
      <tt>CosmologySimulationGridLeftEdge[#]</tt> and <tt>CosmologySimulationGridRightEdge[#]</tt> specify the left and
      right edges of the grid spatially, in units of the box size.  In the last three parameters, "#" is replaced with 
      the grid number.  The root grid is grid 0.  None of the previous three parameters need to be set for the root grid.  
      For the setup described above, the parameter file would be set as follows:</p>

    <p>
      <tt>CosmologySimulationNumberOfInitialGrids = 3</tt><br>
      <tt>CosmologySimulationGridDimension[1]     = 128 128 128</tt><br>
      <tt>CosmologySimulationGridLeftEdge[1]      = 0.25 0.25 0.25</tt><br>
      <tt>CosmologySimulationGridRightEdge[1]     = 0.75 0.75 0.75</tt><br>
      <tt>CosmologySimulationGridLevel[1]         = 1</tt><br>
      <tt>CosmologySimulationGridDimension[2]     = 128 128 128</tt><br>
      <tt>CosmologySimulationGridLeftEdge[2]      = 0.375 0.375 0.375</tt><br>
      <tt>CosmologySimulationGridRightEdge[2]     = 0.625 0.625 0.625</tt><br>
      <tt>CosmologySimulationGridLevel[2]         = 2</tt><br>
    </p>

    <p>Multiple initial grids can be used with or without AMR being turned on.  If AMR is used, the parameter
      <tt>MinimumOverDensityForRefinement</tt> must be modified as well. It is advisable to carefully read 
      the entry for this parameter in the parameter list 
      (<a href="../amr_guide/index-enzo.html#Hierarchy%20Control%20Parameters">in this section</a>), but in
      essence the desired value or values of minimum overdensity need to be divided by r^(d*l), where r is
      the refinement factor, d is the dimensionality, and l is the zero-based highest level of refinement.  
      So if we wish for the
      same values for <tt>MinimumOverDensityForRefinement</tt> used previous to apply on the most highly refined 
      grid, we must divide the set values by 2^(3*2) = 64.  In addition, one should only refine on the highest level, so
      we must reset <tt>RefineRegionLeftEdge</tt> and <tt>RefineRegionRightEdge</tt>.  The parameters would be reset as
      follows:

    <p>
      <tt>RefineRegionLeftEdge = 0.375 0.375 0.375</tt><br>
      <tt>RefineRegionRightEdge = 0.625 0.625 0.625</tt><br>
      <tt>MinimumOverDensityForRefinement = 0.0625 0.125</tt><br> 
    </p>
      
    <p>
      A note:  When creating multi-level intial conditions, make sure that the initial conditions
      files for all levels have the same file name (ie, GridDensity), but that each file has an
      extension which is an integer corresponding to its level.  For example, the root grid GridDensity
      file would be GridDensity.0, the level 1 file would be GridDensity.1, and so forth.  The parameters
      which describe file names (discussed above in the section on initialization parameters) should
      only have the file name to the left of the period the period (as in a simulation with a single
      initial grid), ie,
    </p> 

    <p>
      <tt>CosmologySimulationDensityName          = GridDensity</tt><br>
    </p>
    

    <p>&nbsp;</p>

    <h2>I/O Parameters</h2>
    <p>These parameters, defined in more detail 
      (<a href="../amr_guide/index-enzo.html#I/O%20Parameters">here</a>), control all aspects
      of Enzo's data output.  One can output data in a cosmological simulation in both a 
      time-based and redshift-based manner.  To output data regularly in time, one sets 
      <tt>dtDataDump</tt> to a value greater than zero.  The size of this number, which is in
      units of enzo's internal time variable, controls the output frequency.  See the Enzo user's
      manual section on <a href="../amr_guide/output.html">output format</a> for more information on
      physical units.  Data can be output at specific redshifts as controlled by 
      <tt>CosmologyOutputRedshift[#]</tt>, where # is the number of the output dump (with a maximum
      of 10,000 zero-based numbers).
      The name of the time-based output files are controlled by the parameter 
      <tt>DataDumpName</tt> and the redshift-based output files have filenames controlled by 
      <tt>RedshiftDumpName</tt>.  For example, if we want to output data every time the code
      advances by dt=2.0 (in code units) with file hierarchiess named time_0000, time_0001, etc., and
      ALSO output explicitly at redshifts 10, 5, 3 and 1 with file hierarchy names RedshiftOutput0000,
      RedshiftOutput0001, etc., we would set these parameters as follows:</p>

    <p>
      <tt>dtDataDump             = 2.0</tt><br>
      <tt>DataDumpName           = time_</tt><br>
      <tt>RedshiftDumpName = RedshiftOutput</tt><br>
      <tt>CosmologyOutputRedshift[0] = 10.0</tt><br>
      <tt>CosmologyOutputRedshift[1] = 5.0</tt><br>
      <tt>CosmologyOutputRedshift[2] = 3.0</tt><br>
      <tt>CosmologyOutputRedshift[3] = 1.0</tt><br>
    </p>

    <p>Note that Enzo always outputs outputs data at the end of the simulation, regardless of the 
      settings of <TT>dtDataDump</TT> and <tt>CosmologyOutputRedshift</tt>.</p>

    <p>&nbsp;</p>

    <h2>Radiative Cooling and UV physics parameters</h2>
    <p>Enzo comes with multiple ways to calculate baryon cooling and a metagalactic UV background, as
      described in detail <a href="../amr_guide/index-enzo.html#Parameters%20for%20Additional%20Physics">here</a>.  The
      parameter <tt>RadiativeCooling</tt> controls whether or not a radiative cooling module is called for each grid.
      The cooling is calculated either by assuming equilibrium cooling and reading in a cooling curve, or by
      computing the cooling directly from the species abundances.
      The parameter <tt>MultiSpecies</tt> controls which cooling module is called - if <tt>MultiSpecies</tt> is off (0)
      the equilibrium model is assumed, and if it is on (1 or 2) then nonequilibrium 
      cooling is calculated using either 6 or 9 
      ionization states of hydrogen and helium (corresponding to <tt>MultiSpecies</tt> = 1 or 2, respectively).  
      The UV background is controlled using the parameter <tt>RadiationFieldType</tt>.  Currently there are roughly
      a dozen backgrounds to choose from.  <tt>RadiationFieldType</tt> is turned off by default, and can only be
      used when <tt>Multispecies</tt> = 1.  For example, if we wish to use a nonequilibrium cooling model with a Haardt
      and Madau background with q_alpha = -1.8, we would set these parameters as follows:</p>
    
    <p>
      <tt>RadiativeCooling = 1</tt><br>
      <tt>MultiSpecies = 1</tt><br>
      <tt>RadiationFieldType = 2</tt><br> 
    </p>

    <p>&nbsp;</p>

    <h2>Star formation and feedback physics parameters</h2>
    <p>Enzo has multiple routines for star formation and feedback.  None of these are included in the public release
      version of the code, but we describe the parameters here for completeness.  See 
      <a href="../amr_guide/index-enzo.html#Parameters%20for%20Additional%20Physics">this section</a> of the parameter
      list for more information.</p>
    <p>Star particle formation and feedback are controlled separately, by the parameters <tt>StarParticleCreation</tt> and
      <tt>StarParticleFeedback</tt>.  These routines are disabled when these parameters are set equal to 0, and are turned 
      on when they are equal to 1, 2 or 3.  The value of 2 is the recommended value.  The most commonly used routines 
      (2) are based upon an algorithm by Cen & Ostriker, and there are a number of free parameters. Note that it is 
      possible to turn star particle formation on while leaving feedback off, but not the other way around.</p>

    <p> For the star particle
      creation algorithm, stars are allowed to form only in cells where a minimum overdensity is reached, as defined by
      <tt>StarMakerOverDensityThreshold</tt>.  Additionally, gas can only turn into stars with an efficiency controlled
      by <tt>StarMakerMassEfficiency</tt> and at a rate limited by <tt>StarMakerMinimumDynamicalTime</tt>, and the minimum
      mass of any given particle is controlled by the parameter <tt>StarMakerMinimumStarMass</tt>, which serves to limit
      the number of star particles.  For example, if we wish to use the "standard" star formation scenario where stars
      can only form in cells which are at least 100 times the mean density, with a minimum dynamical time of 10^6 years and
      a minimum mass of 10^7 solar masses, and where only 10% of the baryon gas in a cell can be converted into stars in any
      given timestep, we would set these parameters as follows:</p>

    <p>
      <tt>StarParticleCreation = 2</tt><br>
      <tt>StarMakerOverDensityThreshold = 100.0</tt><br>
      <tt>StarMakerMassEfficiency = 0.1</tt><br>
      <tt>StarMakerMinimumDynamicalTime = 1.0e6</tt><br>
      <tt>StarMakerMinimumStarMass = 1.0e7</tt><br>
    </p>

    <p>Star particles can provide feedback into the IGM via stellar winds, thermal energy and metal pollution.  The parameter
      <tt>StarMassEjectionFraction</tt> controls the fraction of the total initial mass of the star particle which is 
      eventually returned to the gas phase.  <tt>StarMetalYield</tt> controls the mass fraction of metals produced by
      each star particle that forms, and <tt>StarEnergyToThermalFeedback</tt> controls the fraction of the rest-mass energy
      of the stars created which is returned to the gas phase as thermal energy.  Note that the latter two parameters
      are somewhat constrained by theory and observation 
      to be 0.02 and 1.0e-5, respectively.  The ejection fraction is poorly constrained
      as of right now.  Also, metal feedback only takes place if the metallicity field is turned on 
      (<tt>CosmologySimulationUseMetallicityField = 1</tt>).  As an example, if we wish to use the 'standard'
      star feedback where
      25% of the total stellar mass is returned to the gas phase, the yield is 0.02 and 10^-5 of the rest mass is returned
      as thermal energy, we set our parameters as follows:</p>

    <p>
      <tt>StarParticleFeedback = 2</tt><br>
      <tt>StarMassEjectionFraction = 0.25</tt> <br>
      <tt>StarMetalYield = 0.02</tt> <br>
      <tt>StarEnergyToThermalFeedback = 1.0e-5</tt><br>
      <tt>CosmologySimulationUseMetallicityField = 1</tt><br>
    </p>

    <p>When using the star formation and feedback algorithms it is important to consider the regime of
      validity of our assumptions.  Each "star particle" is supposed to represent an ensemble of stars, which
      we can characterize with the free parameters described above.  This purely phenomenological model 
      is only reasonable as long as the typical mass of the star particles is much greater than the mass of
      the heaviest stars so that the assumption of averaging over a large population is valid.  When the typical
      star particle mass drops to the point where it is comparable to the mass of a large star, these assumptions
      must be reexamined and our algorithms reformulated.
    </p>

    <p>&nbsp;</p>

    <h2>IO Parallelization options</h2>
    <p>One of Enzo's great strengths is that it is possible to do extremely large simulations on distributed
      memory machines.  For example, it is possible to intialize a 1024^3 root grid simulation on a linux
      cluster where any individual node has 1 or 2 GB of memory, which is on the order of 200 times less 
      than the total dataset size!  This is possible because the reading of initial conditions and writing out
      of data dumps is fully parallelized - at startup, when the parameter <tt>ParallelRootGridIO</tt> is turned on
      each processor only reads the portion of the root grid which is within its computational domain, and when
      <tt>ParallelParticleIO</tt> is turned on each processor only reads in the particles within its domain (though
      preprocessing is needed - see below).
      Additionally, the parameter <tt>Unigrid</tt> should be turned on for simulations without AMR, as it saves
      roughly a factor of two in memory on startup, allowing the code to perform even larger simulations for a 
      given computer size.  If we wish to perform an extremely large unigrid simulation with parallel root grid and
      particle IO, we would set the following parameters:</p>

    <p>
      <tt>ParallelParticleIO = 1</tt><br>
      <tt>ParallelRootGridIO = 1</tt><br>
      <tt>Unigrid = 1</tt><br>
    </p>

    <p>AMR simulations can be run with <tt>ParallelRootGridIO</tt> and <tt>ParallelParticleIO</tt> on, though 
      you must be careful to turn off the <tt>Unigrid</tt> parameter.  In addition, it is important to note that
      in the current version of enzo you must run the program called "ring" on the particle position and velocity 
      files before enzo is started in order to take advantage of the parallel particle IO.  Assuming the particle 
      position and velocity files are named ParticlePositions and ParticleVelocities, respectively, this is done by
      running:</p>

    <p> 
      <tt>mpirun -np [N] ring ParticlePositions ParticleVelocities</tt><br>
    </p>

    <p>Where mpirun is the executable responsible for running MPI programs and "-np [N]" tells the
      machine that there are [N] processors.  This number of processors <b>must be the same</b> as the 
      number which enzo will be run with!</p>

    <p>&nbsp;</p>

    <h2>Notes</h2>
    <p>
      This page is intended to help novice Enzo users put together parameter files for their first simulation
      and therefore is not intended to be an exhaustive list of parameters nor a complete description of 
      each parameter mentioned.  It would be wise to refer to the Enzo guide's 
      <a href="../amr_guide/index-enzo.html">parameter list page</a> for a more-or-less complete list of AMR parameters,
      some of which may be extremely useful.
    </p>



    <p>&nbsp;</p>
    <p>&nbsp;</p>
    <p>
      <a href="ics_top.html">Previous - Initial Conditions Generator</a><br>
      <a href="index.html">Next - Index</a><br>
    </p>

<p>&nbsp;</p>
<p>
<a href="../index.html">Go to the Enzo home page</a>
</p>
<hr WIDTH="100%">
<center>&copy; 2004 &nbsp; <a href="http://cosmos.ucsd.edu">Laboratory for Computational Astrophysics</a><br></center>
<center>last modified February 2004<br>
by <a href="mailto:bwoshea (AT) lanl.gov">B.W. O'Shea</a></center>


  </body>
</html>
